Real-time multimedia sessions such as Voice over IP calls and videoconferences are highly dependant on the quality of the underlying packet transport network. Problems such as network congestion can materially impact the quality of the voice or video call and lead to dissatisfied users. The present invention provides a means by which the quality of real-time multimedia sessions may be improved.
Real-time multimedia traffic is typically carried in the form of RTP (Real-Time Transport Protocol-IETF RFC3550) frames encapsulated in UDP and IP packets. Some performance feedback is provided by the RTCP (Real-Time Transport Control Protocol-IETF RFC3550) protocol, notably the Receiver Report (RR-IETF RFC3550) and eXtended Report (XR-IETF RFC3611) report types.
In conventional systems, the quality of an RTP stream is measured by receiving system Y and reported using RTCP RR or XR reports to sending system X. These reports are inserted into the packet stream sent from Y to X. A real-time multimedia packet stream therefore comprises a stream of RTP frames from one endpoint system to a second endpoint system into which are inserted reports of the quality of the stream from the second endpoint system to the first.
For example, if RTP(X,Y) denotes an RTP frame being sent from X to Y and RTCP(X,Y) denotes an RTCP report describing the quality of the stream from X to Y then typical streams would resemble:
From X to Y:
RTP(X,Y)- - - RTP(X,Y)- - - RTCP(Y,X)- - - RTP(X,Y)- - - RTP(X,Y)- - - RTP(X,Y)
From Y to X:
RTP(Y,X)- - - RTP(Y,X)- - - RTCP(X,Y)- - - RTP(Y,X)- - - RTP(Y,X)- - - RTP(Y,X)
This is a normal and customary use of the RTP (RFC3550) protocol.
The path taken by the packet stream from X to Y and from Y to X is independently determined by the router within the packet network. This means that the path may, and often is, different for each packet stream. For example, FIG. 1 shows one path 2 a packet may take from endpoint M to endpoint N in a network 8 that includes a plurality of nodes O, P, Q, R, S, and T. A different path 4 is shown from endpoint N to endpoint M.
It is desirable for the routing function to be aware of problems related to congestion as it may affect routing decisions, and may be used to trigger re-routing of calls. This does raise a problem as the router is generally unaware of problems occurring between the router and the receiving endpoint. For instance, node R, a router located between endpoint M and endpoint N in the network 8 depicted in FIG. 1, would be unaware of a network congestion problem at node P because node P is located between node R and endpoint N on the path 2. If node R were aware of the network congestion problem at node P, node F could use a different route for packets to avoid node P, such as path 6 shown in FIG. 2, thereby improving the quality of the multimedia stream. One solution would be for router R to examine performance reports coming from endpoint N, however this is both complex to implement and may be impractical if the packet stream from endpoint N to endpoint M follows a different route than that from endpoint M to endpoint N.
Prior art solutions to this problem include the FECN (Forward Explicit Congestion Notification) and BECN (Backward Explicit Congestion Notification) bits within a Frame Relay frame header, which can be used to throttle traffic based on switch congestion. These are “binary” in operation and are intended only to signal back to a source of packets that it should restrict its output. This would not work in most multimedia applications for several reasons: (a) the packet rate must stay constant in order to meet the delivery requirements of voice or real-time video, (b) in multimedia applications the corrective action is to trigger re-routing or a change in prioritization.
A need therefore exists for an improved solution to this problem that is scaleable to very large networks.